The present invention relates to software development or test environments, and more specifically, to development-time awareness of a production dependency injection environment.
As the pressure to reduce cycle time in software development continues, one of the enablers for “release early, release often” is to have less of a hurdle to jump over to get new versions of applications and services into production. This desire has been channeled into the current culture of development and operations “DevOps” within which “release automation” seeks to allow development to more automatically flow software components from development, through quality assurance, and into production while minimizing costly and error prone manual activities.
To some extent, this extends the reach of developers who deliver “code” downstream which directly controls the task of production system configuration and administration. Thus, to allow for continuous delivery, change management and automation of system provisioning, configuration and control, the concept of “Infrastructure as Code” has arisen. In Infrastructure as Code, artifacts are created by developers that control production.
Dependency injection allows for artifacts like software service implementations to be “injected” into source code, initializing variables to values that are appropriate for the environment the code is running in without the code having to change or actively resolve the values. At one scale, this involves the “scope” the code is running in effecting the particular instance injected, for example the particular transaction, session or application can effect which instance is accessed via a field. At another scale, a common advantage cited when dependency injection arose was that one can have different development, test-scaffolding, and production implementations of services and these are picked up appropriately by the running code which does not need to be modified as it flows from development to test to production.
Java “Contexts and Dependency Injection” (CDI) (Java is a trade mark of Oracle Corporation) provides such a framework for “typesafe” injection. However, it is difficult to work out where the object that is injected is from, whether there is any injection available before the code is run and how what might be injected may vary from development to test to production. To some extent this goes against the DevOps ethos as it makes it harder for the developer to be fully aware of what will run in production and thus makes delivery to the production environment without the traditional systems/production test more risky.
Even once an application has safely passed test and is running in production, on updating an application, it is hard to envisage whether an update has caused some undesirable consequences.
In any environment, whether development, test or production, what is actually injected depends on the eligible artifacts that are found on the classpath.
This depends on what the code looks like (whether the class is of the right type, good constructor, good qualifier etc.). This is commonly inferable by the developer using change control and versioned library systems. However, occasionally the developer and production environments can become out of sync, particularly if servicing multiple releases of the code.
This also depends on what is installed, namely artifacts present in the environment in the server, shared libraries or packaged with the application, and what the classpath is in the production environment. These factors are less commonly available and are usually only available statically after the fact in problem determination scenarios.